nxteach NAF exam 15.5.2012

Here are some sample aspects for each of the exam question. Note that I list them here as bullet points while in the exam the goal was to write essays showing understanding and insight of the topic.

• HTML5 for mobile apps

  • the answer covered the mobile aspects
  • Examples of pros
    • write once, run on all platforms
    • developer competence reuse, same tools work everywhere
    • possibility to access sensor data (e.g. location) (but not all relevant data is accessible)
    • no app store fees, free from app store gatekeeping
    • no need for explicit software installation or update installation
  • Examples of cons
    • not all html5 features available in all platforms
    • some implementation differences in different platforms (most notably IE)
    • standardization still ongoing => some APIs still change
    • not possible to access all features that a native app can
    • performance (especially is performance critical apps like games)
    • regular monetization via app store sales does not work (unless you package the solution to app)

• EXI

  • compressed “binary” XML
  • more efficient compression than with general purpose compression programs like gzip
  • less data to send or store, more computation needed to compress and decompress
  • not human readable
  • use similar to XML, same tools apply
  • JSON is often simpler to use (especially if javascript is used anyhow to process the data), EXI more compact (in most cases)
  • useful for transferring of large data volumes, for communication with mobiles with limited resources

• Web application architectures

  • Server-side tempting
    • logic mixed in html
    • easy to get started but easily results into spaghetti code
    • small ad hoc projects
    • E.g. php (comes as part of default apache installation)
  • Server-side frameworks
    • hides the client server separation, framework generates code both for client and server
    • typical enforces model-view-controller approach
    • most of the code executed on server side
    • stageful server side => scalability issues
    • relatively simple client side => works well in many browsers
    • higher learning curve, requires also learning the framework
    • E.g. Google Web Toolkit, Rails)
  • Rich client & REST
    • a lot of code executed on client side (typically JavaScipt), the client asking for data from the server side
    • clear architectural split between client and server
    • client and server technologies independent => freer language choice, separate testing, different clients for the same server
    • the popular direction, lots of new frameworks coming
    • good scalability because of stateless servers, also http infra with caching reduces server load
    • suitable for complex, responsive apps

• WSDL

  • Part of the ws* (together with SOAP, UDDI)
  • Describes the service & interfaces, not the implementation
  • Allows two systems to learn how they can communicated with each other
  • Consists of abstract and concrete parts
  • A machine readable format
  • Can be used to generate stubs both for client and server side code, or to describe the interface of a (SOAP) service
  • Most often used together with SOAP, typically in enterprise applications
  • A bit heavy and complicated approach. In practice many interfaces are quite simple and do not need the full complexity of WSDL
  • For REST based services interfaces are typically described textually
  • Also WADL description language is available for REST based services but it is not widely used